home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 27 / CU Amiga Magazine's Super CD-ROM 27 (1998)(EMAP Images)(GB)[!][issue 1998-10].iso / CUCD / Programming / BlitzList / BlitzListFiles / BlitzC2P.lha / programming / blitz2 / programs / BlitzC2P.Readme next >
Encoding:
Text File  |  1998-07-27  |  7.6 KB  |  172 lines
  1.  
  2. Here are a collection of fast chunky to planar routines for use in your Blitz
  3. programs. I did not write any of these c2p's, I only did what was necessary to
  4. get them running as Blitz sourcecode.
  5.  
  6. There are currently 6 c2p's to choose from.
  7.  
  8. c2p030:     Mainly for the 68030
  9.             This c2p is meant to be used mainly on 68030 cpu's. It
  10.             doesn't work all that well on other cpu's. This is a cpu-only
  11.             c2p and does not use the blitter in any way. It is probably
  12.             optimised with 030's in mind.
  13.  
  14. c2p040only: Mainly for the 68040
  15.             This c2p is dedicated mainly to the 68040. It is optimised
  16.             for that processor and works very well on it. Being a 68040
  17.             user myself this is by some marjin the fastest c2p of the lot.
  18.             Came in joint first for anything higher than 040/25 also.
  19.  
  20. c2p040plus: For anything from 68040 upwards
  21.             This routine is kind of generic but aimed at any cpu from
  22.             68040 upwards, so that includes 040/40, 060/50 and 060/66.
  23.             This scrapes in about third place in terms of speed. 
  24.  
  25. c2p060only: Mainly for the 68060
  26.             Apparently this one is written especially for 060 cpu's but
  27.             even so it is not the fastest of the bunch. Just thought I'd
  28.             include it anyay. Probably not designed for good performance
  29.             on lower processors.
  30.  
  31. c2pGeneric: For anything from 68000 upwards
  32.             This is an all-round generic c2p. Performance is generally
  33.             pretty low but there are probably some tradeoffs to give
  34.             general all-round acceptable results.
  35.  
  36. c2pCache  : For anything from 68040 upwards
  37.             This routine is different from the others, written by somebody
  38.             else. It uses some caching tricks to try and go even faster.
  39.             For 040/25 this comes in as second fastest and was also about
  40.             joint first on 060's also. This routine is not designed to
  41.             be used on 030's.
  42.  
  43. Some general performance times for the routines are as follows. These times
  44. are inclusive of having a screen open and being displayed, of the specified
  45. dimensions, in either PAL or DoublePAL:
  46.  
  47. c2p030
  48.   040/25 results:
  49.   320x200 @42fps DoublePAL or 44fps PAL
  50.   320x256 @31fps DoublePAL or 34fps PAL
  51.   320x240 @33.6fps DoublePAL or 36.5fps PAL
  52.  
  53. c2p040only
  54.   040/25 results:
  55.   320x200 @49.65fps DoublePAL or 55.3fps PAL
  56.   320x256 @36.2fps DoublePAL or 42.5fps PAL
  57.   320x240 @39.5fps DoublePAL or 45.5fps PAL
  58.   060/50 results:
  59.   320x256 @50fps PAL
  60.   320x200 @66.1fps PAL
  61.  
  62. c2p040plus
  63.   040/25 results:
  64.   320x200 @46fps DoublePAL or 49.2fps PAL
  65.   320x256 @34.2fps DoublePAL or 37.9fps PAL
  66.   320x240 @37fps DoublePAL or 40.6fps PAL
  67.   060/50 results:
  68.   320x256 @50fps PAL
  69.   320x200 @66fps PAL
  70.  
  71. c2p060only
  72.   040/25 results:
  73.   320x200 @46.0fps DoublePAL or 48.2fps PAL
  74.   320x256 @34.2fps DoublePAL or 37.4fps PAL
  75.   320x240 @37.1fps DoublePAL or 40.1fps PAL
  76.   060/50 results:
  77.   320x256 @50fps PAL
  78.   320x200 @66fps PAL
  79.  
  80. c2pGeneric
  81.   040/25 results:
  82.   320x200 @42fps DoublePAL or 44fps PAL
  83.   320x256 @31fps DoublePAL or 34fps PAL
  84.   320x240 @33.7fps DoublePAL or 36.5fps PAL
  85.  
  86. c2pCACHE
  87.   040/25 results:
  88.   320x200 @47.1fps DoublePAL or @50fps PAL
  89.   320x256 @35.3fps DoublePAL or @38.3fps PAL
  90.   060/50 results:
  91.   320x256 @49.6fps PAL
  92.   320x200 @66.1fps PAL
  93.  
  94. All of the routines except for c2pCACHE allow you to specify the size of the
  95. chunky-to-planar operation. This can be specified any number of times during a
  96. program's execution. c2pCACHE has to have its dimensions set in constants before
  97. compilation. c2p040plus has a self-modifying-code routine that is meant to allow
  98. you to alter some stuff that are normally in constants, but it doesn't work so I
  99. would advise avoiding it. It is not generally necessarily.
  100.  
  101. All you have to do to setup a c2p operation is something along these lines (for
  102. example):
  103.  
  104. InitBank 2,320*256,$10000 ; Fastram chunky buffer
  105. InitBank 0,320*256,$10002 ; Chipram planar buffer
  106. CludgeBitmap 0,320,256,8,Bank(0)
  107. c2pGenericInit{320,256}
  108. c2pGeneric{Bank(2),Bank(0)}
  109.  
  110. Of course, replace the c2pGeneric statements with the ones for the relevent c2p
  111. that you are using.
  112.  
  113. The only exception to this is c2pCACHE. This requires that you cludge bitmaps to
  114. 8 bytes past the start of the planar buffer, and that you tell the c2pCACHE
  115. routine to output to an address 4 bytes past the start of the planar buffer. So
  116. you have to allow for this by reserving a little extra memory. Like
  117. this:
  118.  
  119. InitBank 2,320*256,$10000 ; Fastram chunky buffer
  120. InitBank 0,(320*256)+8,$10002 ; Chipram planar buffer
  121. CludgeBitmap 0,320,256,8,Bank(0)+8
  122. c2pCACHE{Bank(2),Bank(0)+4}
  123.  
  124. As you will also notice, for c2pCACHE there is no c2pCACHEinit{}. The size of the
  125. operation has to be set in constant variables.
  126.  
  127. One thing to note is that you have to define the dimensions of the planar bitmap
  128. in constants. The size of the chunky operation is variable, and is set with the
  129. init{} routines. But it looks like you have to stick to one planar size. It takes
  130. those constants into account when working out where to write data to. In a sense
  131. this is a verticle modulo. Once constants such as #c2pBPLSIZE are set in the
  132. program they cannot normally be altered. You can open other sized screens and if
  133. they use precicely the same amount of data as what you originally specified the
  134. new size will work. If you define that your screen is going to be 320x256, you
  135. are free to re-initialise the c2p routine to do 320x200, 320x256, or perhaps
  136. 320x100 operations at different points in the program, and it will work so long
  137. as you are still outputting to the same planar bitmap size. The only way to
  138. overcome such limitations is to do some self-modifying-code, if you're up to it.
  139. There are no line modulos and generally if you're working in chunky you will only
  140. have one size screen and therefore one size operation throughout the entire
  141. program, regardless.
  142.  
  143. There is/are some routines for c2p's which have modulos and possibly
  144. non-contiguous bitplanes, but I suggest these are hindered and therefore quite
  145. slow. The rules that these c2p's impose can be easily worked around. And I would
  146. suggest that if you want to do hardware scrolling you would be better off doing a
  147. software scroll routine rather than having to have an extra 64 pixels width to
  148. the c2p operation. ALWAYS work in fetchmode 3, or if in AmigaMode, make sure that
  149. bitmaps are aligned to the nearest 64 pixel widths and to the nearest 2 longwords
  150. in memory. The o/s will check that data is 64-bit aligned and use the fastest
  151. datafetch mode (which increases c2p performance). If you should happen to do
  152. hardware scrolling further than 32 pixels horizontally, or your bitmaps are not a
  153. multiple of 64 pixels wide, the o/s will automatically switch the datafetch to
  154. 32-bit mode and you will suffer a performance loss. This is why my notes about
  155. c2pCACHE have placed the bitmaps to the nearest 8 bytes rather than just adding
  156. 4 bytes. NEVER use fetchmode 0 not even for lores screens as this will slash the
  157. c2p performance in half. The o/s, if in AmigaMode, will automatically choose
  158. fetchmodes depending on wether the first byte of bitplane data is aligned to the
  159. nearest 2, 4, or 8 bytes.
  160.  
  161. If you can't get the c2p's working I probably can't do anything about it unless
  162. it's just a blitz problem or one of just getting the thing running. You can email
  163. me, Paul West, at paul@stationone.demon.co.uk
  164.  
  165. I hope you enjoy these c2p routines and are thankful for those talented people
  166. who have created them for public use. You are free to use them and any blitz
  167. source I have added in my implementation examples, for freeware, shareware, and
  168. commercialware. I would be happy to hear of your c2p endeavours, what you're
  169. using it for, how it performs for you on your system, and anything else related.
  170.  
  171. Enjoy.
  172.